交付团队管理_如何建立有效的软件交付团队4个关键组成部分

交付团队管理

开始于：为什么需要构建软件？ (Begin With: Why Do You Need To Build Software?)

There are a many reasons why an organization needs to build and deliver software. Some examples might be:

组织需要构建和交付软件的原因有很多。 一些示例可能是：

• Grow integrated strategic partnerships
  发展综合战略伙伴关系
• Improve internal proprietary processes
  改善内部专有流程
• Quality assurance and business intelligence
  质量保证和商业智能
• Build products and tools that customers will use directly
  构建客户将直接使用的产品和工具

Taking the time to understand the “why” can help you determine how to structure a delivery team and establish long term plans. In many cases an organization may find it has multiple answers to the “why” and this could be a good indicator that a team for each might be a good idea.

花时间了解“为什么”可以帮助您确定如何组建交付团队并制定长期计划。 在许多情况下，一个组织可能会发现它对“为什么”有多个答案，这可以很好地表明每个人的团队都是一个好主意。

创建统一的工作流与功能组 (Create Aligned Work Streams vs Functional Groups)

Before we can dive into the 4 components that make a delivery team successful, we need to address team structure. For years many organizations structured software development teams by the “how” instead of “why”. For example — QA experts and engineers were divided into groups. I’m sure some of the thought process was to build competency within an organization. Unless you are offering those services directly to customers — your goals shouldn’t be building a stellar “QA” or “Engineering” team. You want a high performing “delivery” teams that just happen to be composed of individuals in these roles. Consider objective first, software creation second. Think diversity of perspectives — putting people with different skill-sets and roles together for a common goal will cultivate continuous improvement.

在深入探讨使交付团队成功的4个要素之前，我们需要解决团队的结构。 多年来，许多组织通过“如何”而不是“为什么”来组织软件开发团队。 例如，质量检查专家和工程师被分为几组。 我确信某些思考过程是在组织内部建立能力。 除非您直接向客户提供这些服务，否则您的目标不应是建立一支强大的“ QA”或“工程”团队。 您需要一个高性能的“交付”团队，这些团队恰好由这些角色中的个人组成。 首先考虑目标，然后考虑软件创建。 考虑不同的观点-将具有不同技能和角色的人们聚集在一起以实现一个共同的目标将促进持续的改进。

4个组成部分 (The 4 Components)

I’m going to attempt to describe each component and then give examples of ways a team can implement each one. Understand that every organization and work-stream may be different — so not all may apply.

我将尝试描述每个组件，然后举例说明团队可以实现每个组件的方式。 了解每个组织和工作流程可能都不同，因此并非所有组织和工作流程都适用。

Build is traditionally measured by how well your organization can produce technology that can scale, can be maintained cost effectively, and functions consistently. In addition to these considerations I would also include flexibility. A build team that understands how to work iteratively — applying the correct level of technology & effort to deliver what is necessary is key. The ability to produce quality software in a predictable way is the result of multiple aligned efforts.

传统上，构建是通过您的组织生产可扩展的技术，可以保持成本效益的方法以及一致运行的技术的能力来衡量的。 除了这些考虑之外，我还将包括灵活性。 一支懂得如何迭代工作的构建团队-运用正确的技术水平和精力来交付必要的东西是关键。 以可预见的方式生产高质量软件的能力是多重努力的结果。

Application Portfolio Management & Support: In order to continue building you have to consider what has been built already. One mistake many organizations make is creating dedicated support teams that are not aligned with a work stream. The result is a disenfranchised team and a pile of technology that eats up resources. A team that doesn’t manage its portfolio will also run into serious tech debt issues — ultimately impacting its ability to deliver. Further Reading: (TIME) Tolerate | Invest | Maintain | Eliminate